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Abstract 

The objective of the Thermal Control System 
Automation Project (TCSAP) is to develop an advanced 
Fault Detection, Isolation, and Recovery (FDIR) capability 
for use on the Space Station Freedom (SSF) External 
Active Thermal Control System (EATCS). Real-time 
monitoring, control, and diagnosis of the EATCS will be 
performed with a Knowledge-Based System (KBS). This 
paper describes implementation issues for the current 
version of the KBS. 

The TCSAP KBS is a combination of three distinct 
elements that interact with each other. The first is a 
quantitative model of the EATCS, providing step-wise 
steady state values for any EATCS configuration. The 
model is used in sensor validation and component 
diagnosis by comparing obsen/ed sensor readings with 
their computed values. Inconsistencies between 
observed and expected values imply either 
instrumentat’ion failure or actual off-nominal behavior of 
the EATCS. The second element is a rule-based system 
containing safety critical and non-critical FDIR rules 
focused directly on the EATCS. The rules use both 
quantitative and qualitative values for reasoning and 
diagnosis. Quantitative sensor values are obtained from 
an external source and qualitative representations are 
derived from the history of the quantitative data. The 
third KBS element is the Human Interface (HI). The HI 
implements graphically oriented monitoring and control 
capabilities for the EATCS. The interface attempts to 
" intelligently " support the operator by supplying 
information of the type and quantity most likely needed 
in a given context. The HI also altaws the user to specify 
configuration changes such as the closing or opening of 
a valve. These changes can be transmitted to the 
EATCS hardware as well as affecting the internal KBS 
quantitative model. 

The KBS utilizes conventional software and a real- 
time expert system tool called G2. The use of G2 eases 
development of reasoning techniques required for 


automating the EATCS monitoring, control, and FDIR 
tasks. The resulting KBS utilizes a combination of 
model-based sensor validation, rule-based fault 
descriptions, and model-based diagnosis of 
unanticipated faults. 

EATCS Overview 

The External Active Thermal Control System (EATCS) 1 
of Space Station Freedom (SSF) provides cooling and 
control necessary to maintain elements, systems, and 
components within their required temperature ranges. 
The EATCS design has evolved from the single-phase 
fluid system used in Apollo and Space Shuttle to a two- 
phase system (ammonia liquid and vapor mixture) on 
SSF. Both active and passive components of the 
EATCS can potentially fail or become blocked. As a 
result, a variety of failure modes exist. When this is 
combined with the continuous range of normal operating 
conditions and issues related to two-phase flow, EATCS 
diagnostics can become very complex. 

The Space Station EATCS is a central facility, 
transporting waste heat away from crew quarters, 
experiment packages, computers, DC-to-DC power 
conversion units, etc., and radiating it into space. It 
utilizes ammonia as the working fluid and interlaces via 
heat acquisition devices (HADs) with the habitation and 
laboratory modules, and truss mounted equipment 
where the heat dissipation rates are too high to be 
controlled passively. HADs are heat exchangers and 
cold plates that remove heat directly from fluid systems 
and electronic equipment. Liquid ammonia is supplied to 
the HADs by the EATCS and is vaporized by the 
particular heat load being serviced. The vapor is 
transported to the radiators which reject heat to space. 
Figure 1 shows a functional configuration of the major 
EATCS components included in a single loop or bus. 
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Table 1 shows the number of sensors for the major 
components shown in Figure 1. 

TABLE 1 : Number of Sensors and Location 


utilizes conventional software and a real-time expert 
system tool called G2. 

Model Development and Use 

The internal simulation model used by the KBS for 
sensor validation is an object-oriented reconfigurable 
model centered around the actual major EATCS 
components and their connectivity (Figure 2). The 
model is used in three key areas by the KBS as 
discussed further in this paper: (1) to perform sensor 
validation, (2) to provide transition points for mapping 
sensor data to qualitative states in the RBS, and (3) to 
provide expected operating conditions to the HI. Each 
component modeled contains state variables associated 
with inlet and outlet conditions. These state variables are 
flow rate, temperature, pressure, and quality (vapor mass 
divided by the sum of vapor and liquid mass). 
Constraints are represented by generic rules and 
mathematical formulae that govern the relationships 
among these state variables and their propagation 
through the components of the thermal bus. These 
constraints are based on the laws of physics and 
thermodynamics (e.g. conservation of mass), as well as 
the actual component design parameters (e.g. device 
specific pump head curves). 

Sensor objects can be logically connected at the inlet or 
outlet of any component in the model to represent actual 
sensor locations. At these points, sensor readings can 
be compared with the model-predicted value to perform 
sensor validation and initiate component fault diagnosis. 
Reconfiguration of the model occurs automatically from 
changes in heat loads, pump speed, set point 
temperature, or isolation valve positions in the monitored 
hardware. 


Loc. 

Temp 

Press 

DP 

Flow 

Other 

RFMD 

5 

2 

3 

2 

2 

CV(5) 

5 

0 

5 

5 

0 

Hx (3) 

6 

6 

0 

0 

0 

CP (2) 

2 

2 

2 

0 

0 

Accum (2) 

2 

0 

1 

0 

2 

BPRV 

1 

0 

0 

0 

1 

Cond (2) 

6 

5 

3 

2 

0 

TOTALS 

27 

15 

14 

9 

5 

KBS Overview 

The Thermal Control System Automation 

Project 


(TCSAP) Knowledge-Based System (KBS) is a 
combination of three distinct elements that interact with 
each other. 2 - 3 The first is a quantitative model of the 
EATCS, providing step-wise steady state values for any 
EATCS configuration. The second element is a Rule- 
Based System (RBS) containing safety critical and non- 
critical FDIR rules focused directly on the EATCS. The 
third KBS element is the Human Interface (HI). The KBS 


Several simplifying assumptions were made during the 
building of the model. The foremost simplification in the 
current model is to support only steady state conditions. 
The model "propagates" from one steady state to the 
next without regard to time lags or transient states. 
Another significant assumption is the adiabatic behavior 
(no heat transfer) of all components except heat 
exchangers. Other assumptions in the current model 
are that the bus will absorb the total heat load, and that 
flow will always be in one direction. 

A major goal in building this model was that it be as 
generic as possible, so that maintenance would be 
greatly simplified. Another goal was to have a model 
which could support model-based reasoning for sensor 
validation and component diagnosis. We do not attempt 
to encode a global set of equations or a solution strategy 
in this model. Instead, state variables are propagated 
across components and from one component to another 
either upstream or downstream according to the generic 
constraints previously discussed. This propagation 
occurs until all state variables converge to steady values 
(within some tolerance). 
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Input design and configuration parameters for the model 
include the flow-rate of every cavitating venturi, the 
design heat load of every evaporator, the design heat 
rejection capability for each condenser, the initial 
accumulator positions, and all valve states. The total 
condenser cooling capacity and the estimated average 
condenser subcooling are also calculated. Regularly 
supplied external configuration information includes: the 
heat load on each evaporator, the commanded setpoint 
temperature, and the RFMD motor speed. Using these 
facts and assumptions the KBS model is able to 
propagate between steady states. 



The KBS model is propagated with the assumption that 
the bus is operating nominally. In fact, both nominal and 
off-nominal operating conditions cover continuous 
ranges. For example, if one evaporator has been shut 
down, the re configured bus can still be viewed as 
operating nominally. The bus would reach a new steady 
state reflecting a configuration with one less evaporator. 
Similarly, there is no discrete distinction between off- 
nominal behaviors. Conditions considered nominal in 
one state might represent a fault scenario in a different 
operational mode. An infinite number of combinations 
are possible. This makes the use of a model even more 
appropriate in attempting sensor validation and fault 
diagnosis. 


For sensor validation, the observed sensor readings at 
each point are compared with the corresponding 
computed values in the model. If the two values (sensor 
reading versus computed value) are not within tolerance 
then the sensor is marked as suspect. If sensor 
validation finds a sensor reading to be suspect, then the 
sensor will be monitored for fifteen seconds. Fifteen 
seconds is ample time to allow other sensors to go out of 
their application limit range, indicating that a fault is 
occurring. After fifteen seconds, if the sensor reading 
has not changed or the model still invalidates it, then that 
sensor is automatically failed. A failed sensor on-orbit 
may not be replaceable for several months, so working 
with the instrumentation available is imperative. Each 
sensor definition has the capability of specifying 
backups. A more detailed description of the backup 
sensor implementation is given in the next section (Rule- 
Based System). 

The model-based reasoning for component diagnosis 
portion of the KBS is still in development. Several 
different approaches 4>5.6 t 7 are being implemented in 
parallel efforts. The strengths and weaknesses of each 
technique will be described in a separate report. 

Rule-Based System 

The design intention of the KBS is to represent thermal 
expertise in the same way it is expressed by the thermal 
engineer. The comparison of observed values to 
expected values as described earlier is exactly what a 
human expert does implicitly. Complimenting this model- 
based view of the problem an expert also applies 
heuristics, lessons learned from experience, that can 
often be expressed in the form of if-then rules. The KBS 
uses such forward chaining rules in a Rule-Based 
System (RBS) to perform fault diagnosis. 

The TCSAP RBS attempts to match rule conditions 
against patterns of system status information. The RBS 
has several advantages over traditional table-driven 
approaches to diagnosis which also match sensor 
readings to target values (in tables). The RBS rules 
represent diagnostic knowledge at a high level, allowing 
easier human interpretation, maintenance, and 
meaningful explanation capabilities. The RBS is not tied 
to a specific EATCS configuration. The data-driven 
nature of rule-based systems combined with support 
code for primary and alternate instrumentation allows the 
RBS to degrade more gracefully than a table lookup 
approach. 

The FDIR rules reference qualitative states (e.g. low, 
nominal, high) and trends (e g. decreasing, steady, 
increasing) to aid in development, interpretation, and 
maintenance of the RBS. Each sensor has qualitative 
mappings for current value and trend information®. 

3og Transition points for qualitative states are predefined but 



can be dynamically modified such that a quantitative 
value range corresponding to a qualitative state of "low" 
may be different depending on the current system 
mode. For example (see Table 2), the qualitative state of 
a particular thermocouple might be nominal if the reading 
is above 58°F and below 66°F with a setpoint 
temperature of 62°F. Low, very-low, high, and very-high 
would map to other ranges. The trend of each sensor is 
translated in a similar way. The qualitative trend states 
include: rapidly-decreasing, decreasing, steady, 

increasing, and rapidly-increasing. 

TABLE 2. Quantitative to Qualitative Mapping. 


State 

Transition Points 

VERY-HIGH 

70°F 

HIGH 

66°F 

NOMINAL 

58°F 

LOW 

54°F 

VERY-LOW 



The rules are not tied to a specific configuration or load 
status of the EATCS. System state changes due to heat 
load variation, valve manipulation, or setpoint change 
may all be part of a normal operating plan. Since the RBS 
is integrated with the EATCS model described earlier, 
expected/computed values for a new thermal bus state 
are used to dynamically change transition point ranges. 
These new ranges then map incoming sensor data to an 
appropriate qualitative state. Figure 3 shows a simplified 
FDIR rule and some of the types of qualitative 
terminology used. 


if rfmd-motor-speed is rapidly-decreasing and 
rfmd-end-to-end-deltap is low and 

then 

... and 

send-alarm("Evidence of an RFMD motor 
failure", medium-priority) 

Figure 3: The FDIR rules reference 
qualitative states and trends. 


Table-driven systems and traditional rule-based 
implementations tend to degrade rapidly in the presence 
of failed sensors. In the TCSAP RBS, if a sensor has 
been failed by the model-based sensor validation routine 
the system attempts to automatically use backups. If a 
sensor that has been failed has a backup, then the 
backup sensors' reading will be provided for the failed 
sensors’ reading. This allows the FDIR rules to function 
without change even if the primary sensors they refer to 
have failed. A backup sensor can be an actual sensor or 
a calculated value (e.g. a delta pressure calculated by two 
existing and "good" pressure sensors). If an actual 


sensor exists that can be used as a backup sensor for 
another, then the actual sensor is preferred over a 
calculated value. 


Human Interface 


The Human Interface (HI) allows the operator to monitor 
the status of the EATCS hardware and to understand the 
reasoning behind KBS messages and activities. G2 
allows the HI to be built interactively on windows, called 
workspaces. Note that multiple workspaces may exist on 
the screen at a time. A workspace called the Schematic 
Browser allows quick and easy access to different 
contexts and varying levels of detail. Figure 4 shows the 
check-box format of the Schematic Browser workspace. 


Schematic Browser 

I 

□Status at a Glance 
□Global Param. 
□Sim. Facilities 

□Sim. Overview 

□ Misc. Functions 

□ FDIR Timelines 

□ RODB Data Link 


\L 


□ n 

E 1 


□Bus Overview 
□ Evaporator Section 
□Coiled HX 

□ Proto. Plate Fin HX 
□Devel. Plate Fin HX 
□SFE Cold Plate HX 

□ Plate Fin Cold Plate HX 
□Transport Section 

□Accumulators 

□ RFMD 

□ BPRV 

□Condenser Section 

□ Shear Flow Cond 

□ Plate Fin Cond 


Figure 4: 


Schematic Browser. 


The Status-at-a-Glance workspace (Figure 5) was 
developed to show the relationships between key 
values and is generally the most useful for monitoring 
purposes 9 . Since the EATCS is designed to maintain a 
constant heat sink temperature for station heat loads, the 
evaporator liquid supply temperature is a crucial measure 
of system performance and status. At the top of the 
screen are the Evaporator and Setpoint/System 
temperatures. At the bottom of the screen the exit 
quality and subcooling are used to present high-level 
evaporator and condenser loop status. The Mass 
Gauging and RFMD displays in the center show the 
status of transporting liquid and vapor throughout the 
system. By normalizing the observations with their 
expected values, a high or low sensor reading is 
immediately visible as an extension of its bar chart above 
or below the normalization (horizontal) line. 
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The FDIR Timeline workspace notifies the operator of 
sensor validation and diagnostic messages (Figure 6). 
By clearly distinguishing between sensor validation 
messages, low priority fault messages, medium priority 
fault messages, and high priority fault messages, the 
Timeline gives the operator several tools for handling 
crucial messages and delaying action on lower priority 
information. In a real-time situation several messages can 
scroll off the Alarm workspace before the operator has a 
chance to respond. Each time a message is sent from 
the KBS to the Human Interface, the corresponding 
Timeline shows a "Blip". Any messages that might have 
scrolled off of the Alarm workspace too quickly are still 
visible as blips on the Timeline. The blips visually 
represent time-relative placement of each message to 
the other messages. By selecting the icon beside the 
desired message timeline, an operator can display 
messages of that specific priority on a separate 
workspace. Selection of individual messages allows 
access to more specif ic information about the diagnosis. 
The WHY option on a message displays time histories of 
sensors, pseudos, and simulated values pertinent to the 
diagnosis. 



The second column on the Schematic Browser 
references workspaces that present a more detailed 
placement of instrumentation than the Status-at-a- 
Glance screen. These can be displayed individually as 
the Evaporator, Transport, and Condenser sections of 
the bus. They can also be displayed simultaneously 
using the Bus Overview selection. 

The component schematics show the highest level of 
detail available through the HI. These screens present 
individual evaporators, condensers, accumulators, the 
BPRV, the RFMD, and all available instrumentation for 
each. 

The Simulation Facilities and Simulation Overview 
screens provide a view of the internal KBS model 
readings. These show exactly where the KBS expects 
the hardware to be and allow the operator to manually 
adjust key parameters of the internal simulation. 

A sample sequence of actions might begin with a flight 
controller observing an increase in total quality on the 
Status-at-a-Glance screen. The controller then displays 
the Evaporator Section to determine if any or all of the 
evaporator outlet temperatures are high. Subsequent 
actions might take the controller directly down to a 
detailed evaporator schematic or over to view the 
Transport Section. As the anomaly continues, the KBS 
issues messages validating the sensors and warning of 
"Evaporator Blockage" on a single evaporator. This 
activates an Alarms workspace and brings it to the top of 
the screen. By now, the controller may have gone to the 
Simulation Overview screen to compare observed 
evaporator loop conditions with calculated predictions 
from the model. Alternatively, the operator might "click” 
on the warning message and request an explanation of 
"WHY” the KBS made this diagnosis. In this example, 
3 U plots of evaporator inlet and outlet temperatures, flow, 















and delta-pressures would be presented. Several 
combinations of these readings could be indicative of 
some type of blockage. 

Summary 

Using a combination of conventional programming, rule- 
based technology, and model-based reasoning, the 
KBS is able to monitor, control, and perform FDIR on the 
SSF EATCS. Using an internal simulation model, the 
KBS can perform sensor validation and component 
diagnosis by comparing observed sensor readings with 
their computed values. The qualitative representations 
mapped by the model and used in the rule-based portion 
of the system increase flexibility and robustness. The 
KBS human interface makes use of data in the internal 
model to focus the controller on areas of inconsistent 
behavior. 
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